在 SIEM 的解決方案，絕大多數都是以軟體形式存在，
因此昨天除了談在地端環境事前、中、後應該在部署 SIEM 時，
應該考慮到哪些需求、議題與環境上的需求。
而除了這些應考量的項目外，
當我們選擇把 SIEM 放在公有雲環境時，
又應多額外考量哪些因素？
今天的規劃、部署與實施，
我們把焦點從地端移到雲端的環境，
來分享我們在雲端上使用 SIEM 時的注意地方。
基本上談雲端上的安全，各家公有雲 AWS、微軟、谷歌等，
都會遵守共同的責任模型 (shared-responsibility-model)，
由雲服務提供商 (CSP) 負責任何支持硬體的安全和維護，
但應用程式與資料數據的保護則是客戶的責任，
因此雲上服務的管理如果不當都會造成服務攻擊面擴大，
成為潛在駭客可以進一步利用的的攻擊風險。
因此基本上公有雲都會提供各項監控機制，
但各個 AP/DB/SaaS 的安全性確保，還是得由各個客戶來負責。
公有雲第一名的業者目前仍為 AWS，
主打最優異的高可用率、最完整的雲端應用與相關保護措施，
而在目前整體市占率而言，也是 AWS 獨佔鰲頭。
目前在 AWS 與日誌有關聯的服務項目，
包含透過以 S3 Bucket 為主導的 Log Buckets：
Amazon S3
Amazon CloudWatch
而由微軟 Microsoft 主導的公有雲，
主打生態系戰略的 Azure，
圍繞各式微軟關鍵生產應用的公有雲生態系，
而在其上關於日誌收集管理的服務，大概有：
Linux / Windows VMs
Event Hubs
最早在台灣落地資料中心的 Google Cloud Platform，
主打在地化、資料境內法規遵循及 Goolge 自身業務，
在另外兩位公有雲業者尚未在台灣有正式營運的機房前，
常吸引許多政府與金融領域客戶選擇使用。
而在其上的日誌相關的服務與功能有：
Pub/Sub*
Stackdriver Logging*
以上是簡單先針對三大公有雲上，
整理出跟日誌蒐集、威脅偵測有關聯的服務，
無論功能多與少，都是公有雲原生提供的資安監控服務。
而在雲上部署 SIEM 時，
常見有幾個技術議題會碰到以及需要討論：
當我們規劃把 SIEM 放在公有雲時，
雲端上既有的日誌、監控與分析服務，
都會是需要去考慮拆分與 SIEM 重疊的範疇，
例如 Log 能否先利用 S3 Bucket 機制，
做日誌湖 (Data Lake) 後，再進 SIEM 做關聯分析？
或是哪些雲端日誌服務可以直接利用雲平台運用？
無論 SIEM 的核心角色是部署在雲端或地端，
無可避免的都會面臨日誌 over Internet 傳輸的需求，
尤其有些公有雲的計價模式是採 Outbound、不看 inbound，
如果 SIEM 放雲端，就能夠享受到網路頻寬免費的效益，
但反面就是得面臨日誌集中化在雲端的客戶接受度；
反之如果 SIEM 放地端，可以讓客戶大幅度維持以往地端作業生態，
而把雲端日誌透過 Collector 等機制送到地端，
但長期的網路傳輸費用，就會是維運 Cost 的計價一環。
採用公有雲的最大優勢能夠即時滿足 Peak 的使用，
這個資源容易擴充的特性，
可以讓 SIEM 在未來的日誌增長、
需要更多關聯分析的運算資源時，可以按需成長與擴充；
如果 SIEM 架構放在地端層面，
可能就必須從傳統 IT 層面來增加相關資源，
相較雲資源的拓展運用，還是會較為麻煩與複雜。
部署實施速度
在雲端的部署，相對地端環境建置，
可以更快的啟用與執行 SIEM 的相關服務。
專業知識比較
如果要從頭到尾地端部署 SIEM，牽涉到地端的環節會比雲端多得多，
而如果使用基於雲服務的 SIEM，相關專業性的技術與基礎設施會相較單純。
資本支出 vs 用量支出
透過直接採用雲服務的支出，跟傳統採購 IT 設備跟軟體授權，
都會讓 IT + Security 的維護上需要考量未來的擴充性，
但如果直接採用 SaaS 服務則可以只單純考量軟體授權的增長，
維護上會直接以 CSP 的每月用量計價為主，
可以從資本支出模型轉移到到營運費用模型，
從每月營運收入的角度看待資訊安全的投資與費用。
昨天我們透過簡單介紹 SIEM 在地端的規劃、部署與實施，
今天我們繼續介紹 SIEM 在雲端上使用的考量與注意事項，
希望能讓邦友對於在地端、雲端部署 SIEM 都有初步的概念。
明天開始我們會開始進入到談 SIEM 的應用，包含：
SIEM 與 SOC 的關聯
SIEM 與 MSS/MDR 的關聯
期待明天繼續與你／妳空中相見。
iThome鐵人賽
看影片追技術